分散式資料庫理論上會把業務的loading平均分佈到各個node上。但是仍有可能因為業務邏輯或者資料庫本身的機制導致失衡，熱點便是這些情況下的產物。loading只落在其中一個node上，導致整個cluster的效能低落。

TiDB的熱點是怎麼產生的，與資料分配的Key ID有關。TiDB對每一張表、索引、每一行資料都會分配一個ID。
TiKV保存資料的方式是把一連串連續的Key保存在一個Region裡，當達到特定大小的時候，會分裂成兩個Region。
當我們寫入的資料是依序的，如前面提到的Auto_increment，此時Region雖然會因為資料持續寫入達到設定的大小而分裂出新的Region，但是實際上還是針對一個Region做寫入。遇到高併發的寫入時便對寫入產生了熱點。

我們可以從grafana的監控上查看目前是否存在讀/寫的熱點。

也可以下語法查看

select * from information_schema.TIDB_HOT_REGIONS where type = 'read'
select * from information_schema.TIDB_HOT_REGIONS where type = 'write'

讀取的熱點通常發生在表的本身資料不多，所以region也少。TiKV提供了Load Base Split的方式，依據這兩個參數split.qps-threshold與split.byte-threshold，每十秒QPS與流量的統計值來協助判斷是否要拆分新的Region。qas預設是3000，流量則是30MB/s。

寫入熱點的解決分式，則可以透過SHARD_ROW_ID_BITS把ROWID寫入不同的Region，但是在使用上只限於使用NONCLUSTERED Primary Key的表。除此之外也可以用AUTO_RANDOM替換AUTO Increment。